敏捷開發強調每次衝刺交付的成果都是最小可行性，可以自行交付端到端（End to End）的產品或服務，但一個基本資料的新刪修功能，歷經一個衝刺還無法完成，甚至開發時間3~4個月，產品都還在停留在基礎資料維護的功能。那時的我，心想怎麼敏捷一點也不快啊!!

回想那時候開會時，我們精雕細琢的討論著每一項需求規格，甚至針對一個畫面的文字，就可以討論的非常之久，現在回頭想起，才知道原來我們走了甚麼冤枉路。剛從傳統瀑布式專案管理風格轉換到敏捷風格的團隊，最常遇到第二個卡關之處是：如何將 User Story 拆分到足以在一個 sprint 內完成的顆粒度？

敏捷的能力從產品的角度來看，就是能夠儘早獲得市場回饋的能力。這對於習慣於大而全進行設計的IT人員來說卻是是一個挑戰，因為整個設計的過程是貫穿整個開發的過程，每來一個需求都需要進行一次設計工作。所以對於是否打開敏捷能力的切分，我建議還是因不同情況而抉擇。一次製作10個功能，和10個功能一次一次的做，顯然第二種方法更費勁一些。但你不能因為一次做一個功能費勁，就不去選擇這種方式。可能反覆運算的一次次的製作從產品角度來說就是非常正確的道路。所以要警惕技術開發人員慣性思維對切分造成的潛在影響。